Decimal Mul/Div kernels - #9221
Conversation
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Merging this PR will degrade performance by 0.68%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | compress_fsst[(10000, 64, 8)] |
9.6 ms | 10.8 ms | -10.92% |
| ⚡ | Simulation | chunked_dict_primitive_canonical_into[u32, (1000, 100, 100)] |
1.6 ms | 1.5 ms | +10.74% |
| 🆕 | Simulation | mul_decimal_i64_nonnull |
N/A | 1.5 ms | N/A |
| 🆕 | Simulation | div_decimal_i128_nullable |
N/A | 13.1 ms | N/A |
| 🆕 | Simulation | div_decimal_i64_nonnull |
N/A | 3.6 ms | N/A |
| 🆕 | Simulation | mul_decimal_i128_nullable |
N/A | 5.3 ms | N/A |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing mk/decimal-mul-div (5087468) with mk/decimal-scalar-mul-div (a2ecde0)
Footnotes
-
43 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
|
I think we should make codspeed tests slightly smaller |
3 participants
Adds native
MulandDivexecution for decimal arrays, completing the operator set that #8724 started with Add/Sub.p + 1s2p + 12sp + s + 4s + 4Execution
Lanes run at a working width from
decimal_numeric_work_dtype, then narrow to the result's own storage width. The two widths are not always the same: Mul's intermediate is the result itself, but Div scales the dividend by10^result_scalebefore dividing and so needs room forp + |result_scale|digits. A negative result scale scales the divisor instead.DecimalOpConstants<W>hoists the per-execution constants — the result-precision bounds and the two division scale factors — out of the lane loop.Every lane is checked at the working width.
DecimalArraydoes not validate its stored values against the declared precision, so an out-of-precision value can reach a kernel and must not be able to overflow it;test_decimal_value_outside_working_width_errorshas depended on that behaviour since #8724. Overflowing the result precision on a valid lane is an error, as is division by zero; invalid lanes never error.